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MOBILE ACCESS TO LIGHTWEIGHT DIRECTORY ACCES PROTOCOL (LDAP) SERVER 

This application claims benefit of and priority to United States Provisional Patent 
Application Ser. No. 60/365,519, filed March 20, 2002, the entire disclosure of which is 
5 incorporated herein by reference. 

BACKGROUND 

1. Technical Field 

The present invention is directed toward a system and method of handling a 
10 database service request to a database server for a database service. In particular, the 
system and method is directed to enabling cryptographic information stored in database 
servers to be sent to a mobile data communication device ("mobile device") for 
cryptographic e-mail messaging. 

15 2. Description of the Related Art 

A cryptographic e-mail message can be a signed message, an encrypted message, 
or a signed and encrypted message. Standards supporting cryptographic messaging 
include Secure Multipurpose Internet Mail Extensions (S/MIME), Pretty Good Privacy^M 
(PGP™), OpenPGP and other secure e-mail standards and protocols. Cryptographic 

20 information, such as digital certificates, public keys, and the like, is often stored in a server 
accessible over a network, such as a Lightweight Directory Access Protocol (LDAP) 
server. When a cryptographic message is to be sent by a user of a computer device, the 
cryptographic information, such as a public key corresponding to a recipient's e-mail 
address, may not be directly available to the user. The cryptographic information may 

25 instead be obtained by querying the directory of an LDAP server. 
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On a desktop system, the sender may, for example, use a browser program to 
perform a multi-pass query with the LDAP server to select specific cryptographic 
information from the LDAP server. Some actions available to a desktop user, however, 
may not be available to a mobile device user. Furthermore, LDAP queries can return large 
5 responses that may exceed the storage capacity of the mobile device, as well as exceed the 
bandwidth capacity of a wireless network if the mobile device is configured for wireless 
data communication over the wireless network. 

SUMMARY 

10 

A system for handling an LDAP service request to an LDAP server for an LDAP 
service comprises a client pro-am executable on a client system and a handler program 
executable on a handler system. The client program is operable to generate LDAP service 
request data corresponding to the LDAP service and provide the LDAP service request 
1 5 data for transmission from the client system, and further operable to receive LDAP service 
reply data in response to the LDAP service request data. The handler program is operable 
to receive the LDAP service request data transmitted from the client system and execute 
the LDAP service request to the LDAP server, receive LDAP service reply data from the 
LDAP server during one or more passes, and upon completion of the LDAP service, 
20 provide the LDAP service reply data for transmission to the client system in a smgle pass. 

Another system for handling an LDAP service request to an LDAP server for an 
LDAP service comprises a handler program executable on a handler system. The handler 
program is operable to receive LDAP service request data corresponding to the LDAP 
service request and execute the LDAP service request to the LDAP server, receive LDAP 
25 service reply data from the LDAP server during one or more passes, throttle the LDAP 

service reply data to generate throttled LDAP service reply data if the LDAP service reply 

2 
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data exceeds a threshold, and provide the LDAP service reply data or the throttled LDAP 
service reply for transmission to the client system in a single pass. 

A method for handling an LDAP service request to an LDAP server for an LDAP 
service comprises the steps of receiving LDAP service request data transmitted from a 
client system, executmg at the client system the LDAP service request to the LDAP 
server, receiving LDAP service reply data from the LDAP server during one or more 
passes during execution of the LDAP service, and transmitting the LDAP service reply 
data received at the handler system to the client system in a single pass. 

RT^TFP DRS CRIPTION OF THE DRAWINGS ' 

Figs. 1 A and IB provide a block diagram of an illustrative communication system 
in which an LDAP service request is processed; 

Fig. 2 illustrates a system for handling an LDAP service request to an LDAP 

server. 

Fig. 3 provides a flow chart of an illustrative method for handling an LDAP service 
request; 

Fig. 4 is a block diagram of an illustrative client system used in a system for 
handling an LDAP service request, the client system comprising a mobile device; 

Fig. 5 provides a flow chart of an illustrative method for an LDAP client query 
method; 

Fig. 6 provides a flow chart of an illustrative method for an LDAP client record 
reception method; 

Fig. 7 provides a flow chart illustrating a process of generating and executing 
automatic LDAP server queries for data items to be redirected to a mobile device; 
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. Fig. 8 provides a functional block diagram illustrating the handling of a client 
information request by a request handler executed at a handler system; and 

Fig, 9 provides a functional block diagram illustrating the handling of a cUent 
information request by a request handler executed at a server system. 

5 

DETAILED DESCRIPTION 

Figs. lA and IB provide a block diagram of an illustrative communication system 
in which an LDAP service request is processed. The communication system comprises a 
message server 10, the Internet 20, an LDAP server 40, a wireless gateway 85, a wireless 
10 infrastructure 90, a wireless network 105, and a mobile device 100. The LDAP server 40 
is illustratively configured to provide cryptographic information, such as an X.509 digital 
certificate 30. The message server 10 operates a message server software module, such as 
an S/MIME server, and is configured to send and receive S/MIME messages such as 
S/MIME message 50. 

15 The message server 10 may be connected to a carrier or an Internet Service 

Provider (ISP). The user may have an account on the message server 10 so that the user 
may send and receive electronic messages, such as e-mail and the like. Of course, the 
communication system components shown in Fig. 1 may alternatively be connected to a 
wide area network (WAN) other than the Intemet, such as a company-wide WAN. 

20 The message server 10 and the LDAP server 40 may be implemented on one or 

more network computers protected by a firewall program, one or more computers within 
an ISP or Application Service Provider (ASP) system or the like, and provide e-mail and 
LDAP services. Servers such as the message server 10 and the LDAP server 40 may also 
include dynamic database storage engines that have predefined database formats for 

25 calendar data, to-do lists, task lists, e-mail, addresses, documentation, and the like. 

4 
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The wireless gateway 85 and the wireless infrastructure 90 provide a link between 
• the Internet 20 and the wireless network 105, and collectively form an exemplary mobile 
information transfer mechanism. The wkeless infrastructure determines the most likely 
network for locating a given mobile device 100 and tracks the mobile device 100 as it 
5 roams between countries or networks. 

The particular wireless network 105 may be virtually any wireless network over 
which information may be exchanged with a mobile device. For example, the wireless 
network may be a data-centric wireless network, a voice-centric wureless network, or a 
dual-mode network that can support both voice and data communications over the same 
10 physical base stations. Exemplary combined dual-mode networks include the Code 
Division Multiple Access (CDMA) network, the Groupe Special Mobile or the Global 
System for Mobile Communications (GSM) and the General Packet Radio Service 
(GPRS) network, and third-generation (3G) networks such as Enhanced Data-rates for 
Global Evolution (EDGE) and Universal Mobile Teleconununications Systems (UMTS). 
15 Examples of data-centric networks include the Mobitex"™ Radio Network, and the 

DataTAC™ Radio Network. Examples of voice-centric data networks include Personal 
Communication Systems (PCS) networks like CDMA, GSM, and TDMA systems. 

For each type of wireless network 105 and the specific information transfer 
mechanism controlling the forwarding and sending of data items to and from the mobile 
20 device 100, data items, such as e-mail messages, are sent via the wkeless gateway 85 to 

the mobile device 100. An exemplary mobile device 100 may be of the type disclosed in 
United States Patent No. 6,278,442, entitled "HAND-HELD ELECTRONIC DEVICE 
WITH A KEYBOARD OPTIMIZED FOR USE WITH THE THUMBS," the entire 
disclosure of which is incorporated herein by reference. The data items may be sent to the 
25 wireless gateway 85 via a redirector system 1 1 in conununication with the message server 
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10. An exemplary redirection system may be of the type disclosed in United States Patent 
No. 6,219,694, entitled "SYSTEM AND METHOD FOR PUSHING INFORMATION 
FROM A HOST SYSTEM TO A MOBILE DATA COMMUNICATION DEVICE 
HAVING A SHARED ELECTRONIC ADDRESS," the entire disclosure of which is 
incorporated herein by reference. 

The wireless infrastructure 90 includes a series of connections to the wireless 
network 105. These connections can be an Integrated Services Digital Network (ISDN) 
connection, a Frame Relay connection, or a Tl connection usmg the TCP/IP protocol. 

As shown in Fig. 1, the mobile device 100 sends a Uniform Resource Identifier 
(URI) 15 corresponding to a resource request from the LDAP server 40. The URI 15 is, 
for example, an LDAP query for an X.509 digital certificate 30 containing a public key 35. 
The public key 35 is required to encrypt the e-mail message 5 and send the S/MIME 
message 50. The wireless gateway 85 receives the URI 15 and a handler program 
executed at the wireless gateway 85 performs a traditional LDAP query on behalf of 
mobile device 100. The URI 15 arrives at the LDAP server 40, which in turn responds by 
sending a multi-pass response 25 to ttie requesting client. The multi-pass response 25 
may comprise multiple exchanges of data during multiple passes 27. 

The multi-pass response 25 comprises a normal information exchange between the 
LDAP server 40 and the client. In this particular embodiment, the wireless gateway 85 
includes a handler program that manages the LDAP query from the mobile device 100. 
Thus, the requesting client is the wireless gateway 85. Traditional LDAP communication 
techniques are used between the wireless gateway 85 and LDAP server 40. 

As illustrated, information retrieval is performed via a query directed to the LDAP 
server 40 via the URI 15. The LDAP server 40 returns the response 25, which includes 
any results or errors, direcfly to the requestmg client that transmitted the query via the URI 

6 
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15, which in this embodiment is the wireless gateway 85. Typically, the LDAP server 30 
responds in multiple passes 27. 

Although LDAP server 40 is required to return responses whenever such responses 
are defined, the LDAP server 40, and the wireless gateway 85, which is functioning as an 
5 LDAP client, are not required to communicate synchronously. This results in the multi- 
pass response 25 being "chatty" and is not conducive to conducting an LDAP query with 
the mobile device 100 as the LDAP client, as the wireless network 105 and the RF link 
107 are of relatively Ihnited bandwidth and high latency as compared to the Intemet 20. 
The LDAP server 40 provides a directory service over the Intemet 20 whereby 
10 information, such as e-mail addresses, contact information, and cryptographic information 
may be retrieved. One example of such information is a digital certificate 30 having a 
public key 35, which can be retrieved via a query on a Directory Information Tree (DIT) 
served by one or more LDAP servers 40 and 41. Furthermore, since a DIT can be jointly 
provided by one or more LDAP servers 40 and 41, the LDAP server 40 may respond to 
15 the URI 15 with a referral URI 16 directed to the LDAP server 41. The LDAP server 41 
will issue a response 26 to the wireless gateway 85 functioning as the LDAP client in an 
analogous manner as the LDAP server 40 responds to the URI 15, i.e., the response 26 
may comprise multiple passes 28. This referral may make the LDAP exchange even more 
chatty. 

20 The wkeless gateway 85 receives the URI query 15 from the mobile device 100, 

performs the query on behalf of mobile device 100, and responds to the mobile device 100 
with a single pass communication. At least one subset of the information received at the 
wireless gateway 85 in the traditional LDAP multi-pass response 25 is sent and delivered 
in the single-pass response 45 to the mobile device 100. Because the wireless network 

25 105 communications over the RF link 107 typically have high latency as compared to 
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communications over the Internet 20, the single-pass response 45 makes better use of 
resources for transmitting over a RF Unk 107 and wireless network 105. Thus, the 
wireless gateway 85 shields the wireless network 105 from the "chatty" nature of 
traditional LDAP communications by performing the traditional LDAP query on behalf of 
5 a mobile device 100. 

In the case of cryptographic directory service, the LDAP server 40 is used to obtain 
a digital certificate 30 having a public key 35 required to encrypt an e-mail message 5. 
Different cryptographic standards may be used in the communication system, resulting in 
different types of cryptographic information being received. For example, in the case of 
10 X.509 cryptographic information, the LDAP server 30 may provide one or more attributes, 
such as "userCertificate", "cACertificate", "authorityRevocationList", 
"certificateRevocationList", "crossCertificatePaif', "supportedAlgorithms", and 
"deltaRevocationList". 

The data are usually transmitted over the wireless network 105 in binary form, and 
15 the response 25 to the URI 15 may comprise a relatively large amount of data. For 

example, a query for a digital certificate 30 comprising a long certification patii may yield 
a response that includes the certification authority (CA) certificates signed by multiple 
authorities up to a root CA, or may return more than one certificate. Therefore, in addition 
to the traditional LDAP response 25 received by the wireless gateway 85 being chatty, the 
20 response 25 may also be too large for the relatively limited bandwidth of wireless network 
85. Furthermore, if the mobile device 100 has a limited memory store, data from the 
response 25 may also exceed the limited capacity of memory store of the mobile device 
100. 

Thus, the single-pass response 45 may also be "throttied" and compressed to 
25 compensate for the low bandwidtii of the wureless network 105 and the RF link 107. 

8 
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Accordingly, the wireless gateway 85 shields the wireless network 105 and the RF 
interface 107 from an LDAP server response comprising a large amount of data. 

Thus, when the wireless gateway 85 sends a URI query 15 for cryptographic 
information on behalf of the mobile device 100, then the mobile device 100 receives the 
5 single-pass throttled and compressed response 45 suitable for the low bandwidth, high 
latency wireless network 105 and RF link 107. The mobile device 100 is thus enabled to 
encrypt the e-mail message 5, and is thereby able to send a cryptographic message 50 
using cryptographic information obtained over the wireless network 105 and RF link 107. 
Fig. 2 illustrates in greater detail a system for handling an LDAP service request to 
10 an LDAP server. The mobile device 100 is configured to operate an LDAP client software 
module 200, and an e-mail client software module 300 having a cryptographic processing 
block 350. The wireless gateway 85 is configured to operate an LDAP handler software 
module 400 and mobile e-mail agent software module 500. The message server system 10 
is configured to operate a message server software module 700, such as an S/MIME server 
15 software. The LDAP server system 40 is configured to operate an LDAP server software 
module 600. 

The message server system 10, the LDAP server system 40, and the wireless 
gateway 85 may be implemented on any variety of computing devices, such as a computer 
having one or more processors, a memory storage subsystem, and one or more network 
20 interface cards configured to conamunicate over the networks illustrated in Fig. 1. An 
exemplary mobile device is as previously described and as further described below with 
reference to Fig. 4. 

A user of the mobile device 100 may compose, reply to, or forward an e-mail 
message 5 to another user having an account on the message server system 10. The e-mail 
25 message 5 is to be encrypted into an S/MIME message 50 according to the S/MIME 

9 
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Standard. However, the crypto block 350 requires at least one public key 35 
corresponding to a private key of the recipient of the e-mail message 5. The public key 
35, however, is not stored in a memory store of the mobile device 100, and thus the user of 
the mobile device 100 must send a query to an LDAP server 40 to obtain the public key 
35. 

The e-mail client 300 provides an e-mail address 7, or alternatively a common 
name or other user information, corresponding to the intended recipient(s) of the e-mail 
message 5 to the LDAP client 200, which in tum formulates a URI 15 that requests the 
digital certificate 30 corresponding to the recipient. The URI 15 is transmitted to the 
wireless gateway 85, and the LDAP handler software 400 executes the LDAP query to the 
LDAP server 40. The LDAP server software 600 receives the URI 15 and provides the 
multi-pass response 25, which includes the digital certificate 30, back to the wireless 
gateway 85. Upon completion of the LDAP query, the wireless gateway 85 transmits the 
digital certificate 30 to the mobile device 100 in a single pass. 

Fig. 3 provides a flow chart of an illustrative method 800 for handling an LDAP 
service request. At step 810, the mobile device 100 receives a trigger for an event 
requiring LDAP directory information. The trigger in the exemplary embodiment 
described with reference to Figs. 1 and 2 is an encryption command to encrypt an e-mail 
message 5. As previously described, the encryption operation requires the public key 35 
of the digital certificate 30, which is stored at the LDAP server 40. Of course, other 
events may also be used to trigger other LDAP services, such as acquiring an e-mail 
address, contact information, or other data stored in the LDAP server 40. 

In step 815, a URI query is generated. The query is illustratively a standard LDAP 
query. The URI may include known LDAP data such as the protocol prefix ''Idap://"; a 
domain name host such as the domain name for a root CA, such as "directory.ldap40.com" 

10 
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corresponding to the internet address of the LDAP server 40; an optional port number over 
which a stream is initiated, such as the default port ":389'\ and optional base query DN 
followed by other known LDAP query parameters. Thus an example URI generated by 
the mobile device 100 would be 'ldap://directoryidap40.com:389/{optional parameters}". 

In step 820, the URI 15 query is sent to the LDAP handler 400 at the wireless 
gateway 85. Note that the URI 15 query is not sent directly to the Internet address 
corresponding to domain name "directory.ldap40.com", but instead is sent to the wireless 
gateway 85 for further processing by LDAP handler software 400. This can be 
accomplished by sending the URI 15 query as payload data in a conmiunication directed 
to the wireless gateway 85, for example. Other methods for directing the URI 15 query to 
the LDAP handler software 400 at the wireless gateway 85 may also be used. 

In step 825, the URI 15 query is sent to an LDAP server 40 by the LDAP handler 
400 on behalf of a mobile device 100. Thus, once the LDAP handler 400 receives the URI 
15 query, the URI 15 query is sent to the Internet address corresponding to the domain 
name in the URI 15. Continuing with the example, the URI 15 query is sent to the Internet 
address corresponding to "directory.ldap40.com". At this step, the LDAP handler 400 
functions as a traditional LDAP client in order to shield the wireless network 85 and the 
RF link 107 from the chatty and bulky LDAP communication. 

In step 830, at least one multi-pass response 45 is received at the LDAP handler 
400. The LDAP handler 400 continues to function as a traditional LDAP client up until 
the response is received, at which point the next step 835 may begin, at which time the 
LDAP handler may also function as an optimized LDAP server with respect to the mobile 
device 100. 

In step 835, a single-pass response having at least a portion of the at least one 
multi-pass response of step 830 is generated. By generating the single pass response 45 to 

11 
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the URI 15 query, the LDAP handler 400 shields the mobUe device 100 from the chatty 
LDAP communication. 

Step 840 determines if the single-pass response 45 is too large for the limited 
bandwidth of the wireless network 105 and the RF link 107, or for the limited storage 
5 capability of the mobile device 100. AU multiple passes 27 need not be received in order 
to make this determination. For example, steps 830, 835 and 840 may concurrendy 
cooperate and monitor the received LDAP data and the single pass response being 
generated. Then, if a URI 15 query woTild normally return a multi-pass response having 
100 records, step 840 may determine that the response is too large after a threshold, such 
10 as a threshold number of records, has been received. The determination can thus be made 
before the 100 records of the multi-pass response are ftilly received at step 830. 

If the response is determined to be large, then step 845 ensues; or else step 850 

ensues. 

In step 845, the single-pass response 45 is ttirottled. Throtfling limits the data to 
15 be transmitted to the mobile device 100. For example, if a threshold number of records 
received is exceeded, then the LDAP handler 400 may delete the records that are 
subsequently received after the reception of the threshold record. Furthermore, additional 
refinement data may be appended to the retained records. Upon receiving the throttled 
single pass response, the LDAP client 200 operating in the mobile device 100 may then 
20 advise the mobile user to refine the URI query to receive subsequent or alternate records. 

In step 850, the single-pass response is compressed. The single-pass response is 
more amenable to compression because single-pass data packets tend to be fuller than 
multi-pass packets - and thus more likely to have redundancies, which can be compressed, 
for example, by run length encoding or other known encoding schemes. 
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In step 860, the single-pass response is sent to the mobile device 100, and in step 
860, the single pass response is received at the mobile device 100. In step 865, the single- 
pass response is decompressed. 

In step 870, the LDAP directory information is extracted from the single-pass 
5 response. The mobile device 100 thereafter has available to it the requested information 
that was stored at the LDAP server 40. 

In step 875, the mobile device 100 determines if the requested LDAP directory 
information required at step 810 was extracted at step 870. If the requested LDAP 
directory information is present, then step 885 ensues. If the required information is not 
10 present, then step 880 ensues. 

In step 880, the URI 15 query may be refined to further throtde subsequent single- 
pass responses or refine the search at the LDAP server 40, This may be desirable, for 
example, if a record in step 845 is provided in the single-pass response advising the user to 
further refine the URI query after truncating the record set to wittiin a threshold size; or if 
15 the single-pass response indicates that no data responsive to the URI 15 query is available 
at the LDAP server 40. If the mobile device 100 user refines the URI query, then step 820 
and subsequent steps are executed anew. 

In step 885, the action requiring the LDAP directory information is optionally 
executed. For example, a public key 35 in the digital certificate 30 can be used to encrypt 
20 the e-mail 5 into the S/MIME e-mail 50, which is then sent from the mobile device 100. 
The user can preferably be provided an option to not execute the action, however, such as 
by the mobile device 100 generating a user prompt at an I/O device. For example, the user 
may be prompted to confirm the encryption of e-mail message 5 using the public key 35, 
and/or to send the e-mail message 5 or S/MIME e-mail 50. 



wo 03/079639 PCT/CA03/00407 

In an alternate embodiment, step 810 need not necessarily occur at the mobile 
device 100. For example, the wireless gateway 85 may also receive an S/MIME message 
50 to be transmitted to the mobile device 100, If the S/MIME message 50 to be 
transmitted to the mobile device 100 is signed with a digital signature, the pending 
5 transmission can be a trigger event to cause LDAP handler software 400 at the wireless 
gateway 85 to pre-emptively query the LDAP server 40 to obtain the certificate 30 and 
public key 35 for the signer of the S/MIME message, as well as any certificate revocation 
lists or other cryptographic information required to verify the S/MIME message. The 
cryptographic information may then be obtained before the S/MIME message 50 is 
10 transmitted to the mobile device 100, in which case the S/MIME message 50 is stored at 
the wireless gateway 85. The LDAP handler software 400 may be further operable to 
discard the S/MIME message 50 if the signature verification fails and/or is not trusted, or 
alternatively transmit the digital certificate 30 retrieved with the S/MIME message 50. In 
another embodiment, the wireless gateway 85 is configured to verify a digital signature 
15 and transmit the S/MIME message 50 with a verification result of valid or invalid, thus 
conserving processing resources at the mobile device 100. 

In another altemate embodiment, the redirector system 1 1 may store and execute 
the LDAP handler program. If the S/MIME message 50 to be redirected to the mobile 
device 100 is signed with a digital signature, the pending transmission can be a trigger 
20 event to cause LDAP handler software 400 at the redirector system 1 1 to pre-emptively 
query the LDAP server 40 to obtain the certificate 30 and public key 35 for the signer of 
the S/MIME message, as well as any certificate revocation lists or other cryptographic 
information required to verify the S/MIME message. The cryptographic information may 
then be obtained before the S/MIME message 50 is redirected to the mobile device 100, in 
25 which case the S/MIME message 50 is stored at the redirector system 1 1 . The LDAP 
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handler software 400 may be further operable to discard the S/MIME message 50 if the 
signature verification fails and/or is not trusted, or altematively transmit the digital 
certificate 30 retrieved with the S/MIME message 50. In another embodiment, the 
redirector system 1 1 is configured to verify a digital signature and transmit the S/MIME 
5 message 50 with a verification result of valid or invalid, thus conserving processing 
resources at the mobile device 100. 

Fig. 7 provides a flow chart 1200 illustrating one such process of generating and 
executing automatic LDAP server queries for data items to be transmitted to a mobile 
device 100. The process is illustratively carried out at the wireless gateway 85 in a similar 
10 manner as described above. In step 1202, the wireless gateway 85 receives a data item to 
be transmitted to a mobile device 100. The data item may be, for example, an S/MIME 
message 50 including encryption data, such as a digital signature. 

In step 1204, the wireless gateway 85 scans the data item to determine if the data 
item includes encryption data. If the data item includes encryption data, such as the digital 
15 signature, then step 1206 is performed; or else step 1220 is performed. 

In step 1206, a URI query is generated and sent to the LDAP server 40. The query 
is illustratively a standard LDAP query, as described above. Steps 1208, 1210, 1212, 1214 
and 1216 are then performed in a similar manner as described with reference to steps 830, 
835, 840, 845 and 850 of Fig. 3. In step 1218, the single pass response is appended to the 
20 data item. Step 1220 is then executed, and the data item is sent to the mobile device 100. 
Because step 1218 appends the single pass response to the data item, the mobile device 
100 receives all required cryptographic information from the LDAP server 40 for the 
verification of the data item upon initial receipt of the data item. Thus, the mobile device 
100 need not generate a URI 15 query. 
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In another alternate embodiment, other cryptographic applications using secure 
socket layer (SSL), such as a web browser application, may require server and/or client 
certificates, certificate revocation lists, and/or other cryptographic information. Use of 
SSL could also be a trigger event occurring, for example, when the mobile device 100 user 
5 browses or is pushed an SSL page. The encryption information may be obtained by the 
mobile device 100 issuing a URI query as described above, or may alternatively be 
obtained by the LDAP handler 400 issuing the URI query as described above. 

In another embodiment, the throttling steps and compression/decompression steps 
are optional. The use of compression as well as throttling allows the method to be adapted 
10 to various wireless network/mobile device combinations to ensure that an acceptable 

trade-off is achieved between minimizing RF bandwidth by compression, and minimizing 
tiie impact of additional mobile device processing by requiring decompression. 
Compression and throttling may be optionally invoked by a user of the mobile device 100, 
or by a system administration, or automatically depending on the size of the single pass 
15 response. 

With reference to Fig. 4, there is a block diagram of an exemplary wireless device 
900 that may be used to realize the mobile device 100. The wireless device 900 is 
preferably a two-way communication device having at least voice and data communication 
capabilities. The device preferably has the capability to communicate with other computer 
20 systems on the Intemet. Depending on the functionality provided by the device, the 
device may be referred to as a data messaging device, a two-way pager, a cellular 
telephone with data messaging capabilities, a wireless Intemet appliance or a data 
conununication device (with or without telephony capabilities). 

When the device 900 is enabled for two-way communications, the device will 
25 incorporate a communication subsystem 911 including a receiver 912, a transmitter 914, 
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and associated components such as one or more antenna elements 916 and 918, local 
oscillators (LOs) 913, and a processing module such as a digital signal processor (DSP) 
920. The particular design of the communication subsystem 911 will be dependent upon 
the communication network in which the device is intended to operate. For example, a 
device 900 destined for a North American market may include a communication 
subsystem 911 designed to operate within the Mobitex. mobile communication system or 
DataTAC mobile communication system, whereas a device 900 intended for use in Europe 
may incorporate a General Packet Radio Service (GPRS) conmiunication subsystem 911. 

Network access requirements will also vary depending upon the type of network 
919, such as the wireless network 105 of Fig. 1. For example, in the Mobitex and 
DataTAC networks, mobile devices such as 900 are registered on the network using a 
unique personal identification number or PIN associated with each device. In GPRS 
networks, however, network access is associated with a subscriber or user of a device 900. 
A GPRS device therefore requires a subscriber identity module, commonly referred to as a 
SIM card, in order to operate on a GPRS network. 

Signals received by the antenna 916 through a communication network 919 are 
input to the receiver 912, which may perform such common receiver functions as signal 
amplification, frequency down conversion, filtering, channel selection and the like, and 
analog to digital conversion. Analog to digital conversion of a received signal allows more 
complex communication functions such as demodulation and decoding to be performed in 
the DSP 920. In a similar manner, signals to be transmitted are processed, including 
modulation and encodmg for example, by the DSP 920 and input to the transmitter 914 for 
digital to analog conversion, frequency up conversion, filtering, amplification and 
transmission over the communication network 919 via the antenna 918. 
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The DSP 920 not only processes conununication signals, but also provides for 
receiver and transmitter control. For example, the gains applied to communication signals 
in the receiver 912 and transmitter 914 may be adaptively controlled through automatic 
gain control algorithms implemented in the DSP 920. 
5 The device 900 preferably includes a microprocessor 938, which controls the 

overall operation of the device. Communication functions, including at least data and 
voice communications, are performed through the communication subsystem 911. The 
microprocessor 938 also interacts with further device subsystems such as the display 922, 
flash memory 924, random access memory (RAM) 926, auxiliary input/output (I/O) 
10 subsystems 928, serial port 930, keyboard 932, speaker 934, microphone 936, a short- 
range communications subsystem 940 and any other device subsystems generally 
designated as 942. 

Some of the subsystems shown in Fig. 4 perform communication-related functions, 
whereas other subsystems may provide "resident" or on-device functions. Notably, some 

15 subsystems, such as keyboard 932 and display 922 for example, may be used for both 

communication-related functions, such as entering a text message for transmission over a 
communication network, and device-resident functions such as a calculator or task list. 

Operating system software used by the microprocessor 938 is preferably stored in a 
persistent store such as flash memory 924, which may instead be a read only memory 

20 (ROM) or similar storage element. The operating system, specific device applications, or 
parts thereof, may be temporarily loaded into a volatile store such as RAM 926. Received 
communication signals and data items may also be stored to RAM 926. The flash memory 
924 preferably includes data communication module 924B, and when device 900 is 
enabled for voice communication, voice conmiunication module 924A. Other software 

25 modules may be stored in other flash memory modules 924N, which illustratively stores 
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software for the LDAP client 200, e-maU client 300, and cryptographic block 350 of Fig. 
2. 

The microprocessor 938, in addition to its operating system functions, preferably 
enables execution of software applications on the device. A predetermined set of 

5 applications that control basic device operations, including at least data and voice 

conamunication applications, for example, will normally be installed on the device 900 
during manufacture. A preferred application that may be loaded onto the device may be a 
personal information manager (PIM) application having the ability to organize and 
manage data items relating to the device user such as, but not limited to e-mail, calendar 

10 events, voice mails, appointments, and task items. Naturally, one or more memory stores 
would be available on the device to facilitate storage of PIM data items on the device. 
Such PIM application would preferably have the ability to send and receive data items, via 
the wireless network. In a one embodiment, the PIM data items are seamlessly integrated, 
synchronized and updated, via the wireless network, with the device user's corresponding 

15 data items stored or associated with a host computer system. Further applications may also 
be loaded onto the device 900 through the network 919, an auxiliary UO subsystem 928, 
serial port 930, short-range communications subsystem 940 or any other suitable 
subsystem 942, and installed by a user in the RAM 926 or preferably a non-volatile store 
for execution by the microprocessor 938. Such flexibility in application installation 

20 increases the functionality of the device and may provide enhanced on-device functions, 
conomunication-related functions, or both. For example, secure communication 
applications may enable electronic commerce functions and other such financial 
transactions to be performed using the device 900. 

In a data conamunication mode, a received signal such as a text message or web 

25 page download will be processed by the conamunication subsystem 911 and input to the 
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microprocessor 938, which will preferably further process the received signal for output to 
the display 922, or alternatively to an auxiliary I/O device 928. A user of device 900 may 
also compose data items such as e-mail messages, for example, using the keyboard 932, 
which is preferably a complete alphanumeric keyboard or telephone-type keypad, in 
5 conjunction with the display 922 and possibly an auxiliary I/O device 928. Such composed 
items may then be transmitted over a communication network through the communication 
subsystem 911. 

For voice communications, overall operation of the device 900 is substantially 
similar, except that received signals would preferably be output to a speaker 934 and 

10 signals for transmission would be generated by a microphone 936. Alternative voice or 
audio I/O subsystems such as a voice message recording subsystem may also be 
implemented on the device 900. Although voice or audio signal output is preferably 
accomplished primarily through the speaker 934, the display 922 may also be used to 
provide an indication of the identity of a calling party, the duration of a voice call, or other 

15 voice call related information, for example. 

The serial port 930 would normally be implemented in a personal digital assistant 
(PDA)-type communication device for which synchronization with a user's desktop 
computer may be desirable, but is an optional device component. Such a port 930 would 
enable a user to set preferences through an extemal device or software application and 

20 would extend the capabilities of the device by providing for information or software 

downloads to the device 900 other than through a wireless communication network. The 
altemate download path may for example be used to load an encryption key onto the 
device through a direct and thus reliable and trusted connection to thereby enable secure 
device communication. 
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A short-range communications subsystem 940 is a further optional component 
which may provide for communication between the device 900 and different systems or 
devices, which need not necessarily be similar devices. For example, the subsystem 940 
may include an infrared device and associated circuits and components or a Bluetooth™ 
5 communication module to provide for communication with similarly enabled systems and 
devices. 

Fig. 5 provides a flow chart 1000 of an illustrative method for an LDAP client 
query carried out at the mobile device 100. In step 1010, a stream connection with an 
LDAP URI is requested. The request may be sent from any computer device in 
10 communication with the wireless gateway 85 over one or more networks. In the case of 
the cryptographic messaging example, the request is sent from the mobile LDAP client 
200 executing on the mobile device 100. 

In step 1020, a stream connection to the LDAP handler 400 is opened. By opening 
this connection to the LDAP handler 400 rather than the LDAP server 40, the mobile 
15 device 100 is shielded from the chatty LDAP information exchange. 

In step 1030, a connection input and output stream is obtained. The LDAP handler 
400 uses the output stream to receive the URI sent in the subsequent step, and the LDAP 
client 200 uses the input stream to receive records from the LDAP handler 400 in the 
single pass response. 

20 In step 1040, the URI is sent to the LDAP handler 400 by writing the URI to the 

output stream. The LDAP handler 400 then proceeds to perform the multi-pass query on 
behalf of the mobile device 100, and returns a throttled, optionally compressed, single- 
pass response as previously described. 

In step 1050, the mobile device 100 determines if the input stream is compressed. 

25 This determination can be made, for example, by reading a Boolean value from the input 



wo 03/079639 PCT/CA03/00407 
Stream, written by the LD AP handler 400 to specify that the option to compress has been 
selected or deselected. If compression is selected, step 1060 ensues before step 1070. If 
compression is not selected, then step 1070 ensues. 

In step 1060, a decompressor stream is applied to the input stream. The 
decompression can be implemented by several methods, such as by pipelining the input 
stream through a decompressor stream and then substitutmg the decompressor stream for 
the input stream in subsequent steps, for example. 

Step 1070 determines if input stream is to receive data. This can be accomplished 
either by receiving a header file specifying the amount of data to be transmitted over the 
input stream, or by reading a Boolean value from the input stream, written by the LDAP 
handler 400, which specifies that either a record is forthcoming, or that all records have 
been sent in the single-pass response, A timeout condition may further ensure that the 
mobile device 100 terminates the communication after a timeout. If input is to be 
received, then step 1080 ensues, else if no input is to be received, then step 1090 ensues. 

In step 1080, a record is read from the input stream. This step defines the record 
format used in the single-pass response, which is specified by either the mobile device 100 
or the LDAP handler 400. An example embodiment of a method to carry out this step is 
illustrated in Fig. 6. After receiving the record, step 1070 ensues to ensure that a single- 
pass is used. 

In step 1090, a listener is notified of reception of the LDAP directory information. 
The listener is illustratively the e-mail client program 300 executing on the mobile device 
100. The listener may then automatically terminate reception of further LDAP query data 
if the required information has been received, or may alternatively prompt the user of the 
mobile device 100 for further direction. 
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Fig. 6 provides a flow chart 1 100 of an illustrative method for an LDAP client 
record reception method. The method of Fig. 6 is iUustrative used to read record from 
input step 1080 of Fig. 5. 

In step 1010, a request to read a record is received. Step 1 120 determines if an 
5 input signal indicates a new entry at the input. This determination can be made, for 

example, by reading a Boolean value from the input, written by the LDAP handler 400, 
which specifies that a new entry is forthcoming in the current record, or that the current 
record appUes to the current entry. If a new entry is at the input, then step 1 130 ensues, or 
else step 1160 ensues. 

10 In step 1 130, a new entry is created. The entry comprises the received attributes of 

the record. 

Step 1 140 determines if at least one entry has been received, i.e., if the entry has 
received aU of its attributes. If the determination is positive, then step 1150 ensues. If the 
determination is negative, then step 1160 ensues. 
15 In step 1 1 50, the listener is notified that an entry has been received, i.e., all of the 

entry attributes have been received. The listener may determine if the entry is the desired 
LDAP directory information, and if so, no additional records need to be received and the 
communication can be terminated. Altematively, the mobile device 100 can be configured 
to prompt tiie user so that the user may determine if the entry is the desired LDAP 
20 directory information. 

Step 1 160 determines if the input has a new attribute. This determination can be 
made, for example, by reading a Boolean value from the input, written by the LDAP 
handler 400, which specifies that a new attribute is forthcoming in the current record. If a 
new attribute is determined, step 1 170 ensues; or else step 1 1 80 ensues to signal that a 
25 record has been read. 

23 



wo 03/079639 PCT/CA03/00407 

In step 1 170, an attribute from input stream is read and added to an entry. This can 
be accomplished, for example, by reading the name of the attribute from the input, written 
by the LDAP handler 400, then reading a Boolean value from the input signalling whether 
the attribute is binary or textual, and reading the binary or textual attribute from the input. 
5 The read attribute is then added to the current entry. 

Step 1 180 ends the record reception method and notifies a listener in the mobile 
device 100 that a record has been read. 

Fig. 8 provides a functional block diagram 2000 illustrating the handling of a client 
information request by a request handler. The information request illustratively is of the 
10 form of an LDAP query; however, other information requests may also be handled by a 
system and/or method as depicted in Fig. 8. A client system may have a client 
information requirement 2002 to be served by an external system, such as an LDAP 
server. The client information requirement 2002 may be a requirement for a digital 
certificate, a public key, particular contact information, or some other information 
15 requirement. The client information requirement 2002 is to be served in a single pass 
communication. 

The client system issues, a request to serve the client information requirement 2002 
to a handler system, which executes a request handler program 2004. The request handler 
program 2004 handles the client information requirement 2002 request for the client 

20 system, and establishes a communication with a server system, or some other computing 
device, which executes a request server program 2006 that responds to the client 
information requirement 2002. The request handler program 2004 receives and monitors 
the multi-pass communication from the server system, and determines if the data received 
from the server system exceeds a client system threshold requirement, such as size or 

25 record count. If the data does exceed the client system threshold requirement, then the 
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request handler program 2004 uses a throttle 2008 to transmit the data received up to the 
threshold requirement to the client system in a single-pass reply communication. If the 
data does not exceed the client system threshold requurement, then the request handler 
program 2004 transmits the data received to the client system in a single-pass reply 
5 communication. 

The throttle 2008 illustratively throttles the received data by limiting the single- 
pass reply communication to a throttled reply 2010. The throttle reply 2010 may not 
include all of the data received in the multi-pass communication from the server, as 
illustrated by the throttled reply 2010 originating at a point within the multi-pass 
10 communication. 

The throttled reply 2010 may be generated by several methods. In one 
embodiment, the request handler program 2004 may receive the entire multi-pass 
communication and store the received data at the handler system. The request handler 
program 2004 may then determine if the received data exceeds the client system threshold 
15 requirement. If the received data exceeds the client system threshold requirement, then the 
- request handler program 2002 selects a subset of the data received and sends the data 
subset to the client system. The request handler program 2004 may optionally include 
refinement data to request the client system to refine the information requirement or 
request the client system to confirm receipt of the additional data received in the multi- 
20 pass response but not sent to the client system. 

In another embodiment, the request handler program 2004 monitors the multi-pass 
communication to determine if the received data exceeds the client system threshold 
requirement. If the received data exceeds the client system threshold requirement, then the 
request handler program 2002 terminates the multi-pass communication and sends the 
25 received data to the client system. The request handler program 2004 may optionally 
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include refinement data to request the client system to refine the information requirement. 
Of course, other methods of throttling the multi-pass communication may also be used. 

While the LDAP handler 400 has been described as a software program executed 
on the wireless gateway 85, tlie LDAP handler 400 may also be a software program 
5 executed on the LDAP server 40. For example, the LDAP handler 400 can be accessible 
via an alternate port on the LDAP server 40. The alternate port may be designated in the 
URI, and thus the URI can be selected to either specify a convention, multi-pass LDAP 
query (e.g., "Idap://....") or a single-pass LDAP query (e.g., "mldap://...."). Furthermore, 
a multi-pass LDAP query may then be converted to a single-pass LDAP query by 
10 modifying the URI, e.g., adding a leading "m" to the URI "Idap://. . to obtain the URI 

"mldap://. . Likewise, a single-pass LDAP query may then be converted to a multi-pass 
LDAP query by stripping the leading "m" to obtain the URI "Idap://. . 

Fig. 9 provides a functional block diagram illustrating the handling of a client 
information request by a request handler executed on a server system. The information 
15 request illustratively is of the form of an LDAP query; however, other information 

requests may also be handled by a system and/or method as depicted in Fig. 9. A client 
system may have a client information requirement 2102 to be served by an external 
system, such as an LDAP server. The client information requirement 2102 may be a 
requirement for a digital certificate, a public key, particular contact information, or some 
20 other information requkement. The client information requirement 2102 is to be served in 
a single pass communication. 

The client system issues a request to serve the client information requirement 2102 
to an intermediate device, illustratively a gateway program 2104 executed on the wireless 
gateway 85. The gateway program 2104 sends the request to a handler program 2106 
25 executed on an LDAP server. The request handler program 2106 handles the client 
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information requirement 2102 request for the gateway projgram 2104, and cpnmiunicates 
with a request server program 21 10 that responds to the client information requirement 
2102. The request handler program 2106 receives and monitors the multi-pass 
communication from the request server program 2110, and determines if the data received 
5 from the request server program 2110 exceeds a client system threshold requirement, such 
as size or record count. 

The client system threshold requirement may be provided to the request handler 
program 2106 v^th the request when transmitted from the gateway program 2104, or may 
alternatively be previously stored and accessible by the request handler program 2106. 

10 If the data does exceed the client system threshold requirement, then the request 

handler program 2106 uses a throttle 2108 to transmit the data received up to the threshold 
requirement to the wireless gateway 85 in a single-pass reply conununication. If the data 
does not exceed the client system threshold requirement, then the request handler program 
2106 transmits the data received to the wireless gateway 85 in a single-pass reply 

15 communication. The gateway program 2104 on the wireless gateway 85 then transmits 
the data received from the handler program 2016 to the client system in a single pass 
communication. 

The embodiments disclosed herein are illustrative, and other configurations and 
communication paths for computer systems distributed throughout one or more networks 
20 lhat enable the functionality of the LDAP handler system as disclosed herein may also be 
used. 

The embodiments described herein are examples of structures, systems or methods 
having elements corresponding to the elements of the invention recited in the claims. This 
written description may enable those of ordinary skill in the art to make and use 
25 embodiments having alternative elements that likewise correspond to the elements of the 
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invention recited in the claims. The intended scope of the invention thus includes other 
structures, systems or methods that do not differ from the literal language of the claims, 
and further includes other structures, systems or methods with insubstantial differences 
from the literal language of the claims. 
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What is claimed is: 

1 . A system for handling a Lightweight Directory Access Protocol (LDAP) 
service request to an LDAP server for an LDAP service, the system comprising: 

a client program executable on a client system, the client program operable 
to generate LDAP service request data corresponding to the LDAP service and provide the 
LDAP service request data for transmission from the client system, and further operable to 
receive LDAP service reply data in response to the LDAP service request data; and 

a handler program executable on a handler system, the handler program 
operable to receive the LDAP service request data transmitted from the client system and 
execute the LDAP service request to the LDAP server, receive LDAP service reply data 
from the LDAP server during one or more passes, and upon completion of the LDAP 
service, provide the LDAP service reply data for transndssion to the client system in a 
single pass. 

2. The system of claim 1, wherein the handler program is further operable to 
throttle the LDAP service reply data to generate throttled LDAP service reply data if the 
LDAP service reply data exceeds a threshold, and provide the throttled LDAP service 
reply data for transmission to the client system in a single pass. 

3. The system of claim 2, wherein the handler program is ftirther operable to 
append refinement data to the throttled LDAP service reply data. 

4. The system of claim 3, wherein the client program is further operable to 
generate revised LDAP service request data in response to receiving the refinement data 
and provide the revised LDAP service request data for transmission from the client 
system. 

5. The system of claim 4, wherein the client system comprises a mobile 
device operable to conmiunicate over a wireless network. 
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6. The system of claim 5, wherein the LDAP service request data comprises a 
Uniform Resource Identifier (URI). 

7. The system of claim 6, wherein the URI comprises an LDAP query for a 

digital certificate. 

8. The system of claim 6, wherein the URI comprises an LDAP query for a 
public key. 

9. The system of claim 3, wherein the handler program is further operable to 
compress the LDAP service reply data and the throttled LDAP service reply data prior to 
transmission to the client system. 

10. The system of claim 3, wherein the LDAP service reply data comprises 
data records, and threshold comprises a record count. 

1 1 . The system of claim 10, wherein the LDAP service reply data is throttled to 
generate the throttled LDAP service reply data by limiting the LDAP service reply data to 
the record count of data records. 

12. The system of claim 1 1 , wherein the LDAP service request data comprises 
an LDAP query for a digital certificate. 

13. The system of claim 12, wherein the handler program is further operable to 
append refinement data to the throttled LDAP reply data and provide the refinement data 
for transmission to the client system. 

14. The system of claim 13, wherein the client program is further operable to 
generate revised LDAP service request data in response to receiving the refinement data 
and provide the revised LDAP service request data for transmission from the client 
system. 
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15. The system of claim 1, wherein the LDAP service request data comprises 
an LDAP query for a digital certificate, and wherein the LDAP service reply data 
comprises digital certificate data. 

16. The system of claim 2, wherein the handler system is operable to redirect a 
5 data itena to the client system, and the handler program is further operable to determine 

whether the data item includes encryption data and upon a determination that data item 
includes encryption data generate automatic LDAP service request data and execute a 
corresponding automatic LDAP service request to the LDAP server. 

17. The system of claim 16, wherein the handler program is further operable to 
10 store the data item at the handler system until the LDAP service reply data is received, and 

then redirect the data item and the LDAP service reply data or the throttled LDAP service 
reply data to the client system. 

18. The system of claim 17, wherein the handler system is a wireless gateway. 

19. The system of claim 17, wherein the handler system is a redirector system. 
15 20. A system for handling a Lightweight Directory Access Protocol (LDAP) 

service request to an LDAP server for an LDAP service, the system comprising: 

a handler program executable on a handler system, the handler program 
operable to receive LDAP service request data corresponding to the LDAP service request 
and execute the LDAP service request to the LDAP server, receive LDAP service reply 

20 data from the LDAP server during one or more passes, throttle the LDAP service reply 

data to generate throttied LDAP service reply data if the LDAP service reply data exceeds 
a threshold, and provide the LDAP service reply data or throttied LDAP service reply data 
for transmission to a client system in a single pass. 

21 . The system of claim 20, wherein the handler program is further operable to 

25 append refinement data to die throttied LDAP service reply data. 
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22. The system of claim 21 , wherein the handler program is further operable to 
compress the LDAP service reply data and the throttled LDAP service reply data prior to 
transmission to the client system. 

23. The system of claim 22, wherein the LDAP service reply data comprises 
5 data records, and the threshold comprises a record count 

24. The system of claim 23, wherein the LDAP service reply data is throttled to 
generate the throttled LDAP service reply data by limiting the LDAP service reply data to 
the record count of data records. 

25. The system of claim 24, wherein the LDAP service request comprises a 
10 query for a digital certificate. 

26. The system of claim 20, wherein the handler system is operable to redirect 
a data item to the client system, and the handler program is further operable to determine 
whether the data item includes encryption data and upon a determination that data item 
includes encryption data generate automatic LDAP service request data and execute a 

15 corresponding automatic LDAP service request to the LDAP server, 

27. The system of claim 26, wherein the handler program is further operable to 
store the data item at the handler system until the LDAP service reply data is received, and 
then redirect the data item and the LDAP service reply data or the throttled LDAP service 
reply data to the client system 

20 28. A method for handling a Lightweight Directory Access Protocol (LDAP) 

service request to an LDAP server for an LDAP service, the method comprising the steps 
of: 

receiving LDAP service request data transmitted from a client system, the LDAP 
service request data corresponding to the LDAP service request; 
25 executing at a handler system the LDAP service request; 
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receiving at the handler system LDAP service reply data from the LDAP server 
during one or more passes during execution of the LDAP service; and 

transmitting the LDAP service reply data received at the handler system to the 
client system in a single pass. 
5 29. The method of claim 28, further comprising the steps of: 

throttling the LDAP service reply data to generate throttled LDAP service reply 
data if the LDAP service reply data exceeds a threshold; and 

transmitting the throttled LDAP service reply to the client system in a suigle pass. 

30. The method of claim 29, further comprising the step of 

10 generating refinement data for the throttled LDAP service reply data; and 

transmitting the refinement data to the client system. 

3 1 . The method of claim 30, wherein the LDAP service request data comprises 
a Uniform Resource Identifier (URI). 

32. The method of claim 31, wherein the URI comprises an LDAP query for a 
15 digital certificate. 

33. The method of claim 30, further comprising the step of compressing the 
LDAP service reply data and the throttled LDAP service reply data prior to transmission 
to the client system. 

34. The method of claim 29, wherein the step of throttling the LDAP service 
20 reply data to generate the throttled LDAP service reply data if the LDAP service reply data 

exceeds a threshold comprises the steps of: 

determining the amount of the LDAP service reply data received; 
comparing the amount of LDAP service reply data received to the threshold; and 
transmitting only tlie threshold amount of the LDAP service reply data received if 
25 the LDAP service reply data received exceeds the threshold. 
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35. The system of claim 34, wherein the UDAP service reply data comprises 
digital certificate data. 

36. The system of claim 34, further comprising the step of compressing the 
LDAP service reply data and the throtded LDAP service reply data before transmission. 

5 37. A method for accessing digital certificate data stored in a Lightweight 

Directory Access Protocol (LDAP) server, the digital certificate data requested by a client 
system, the method comprising the steps of: 

receiving at a handler system a Uniform Resource Identifier (URI) query for the 
digital certificate data, the query transmitted from a mobile device; 
10 executing at the handler system the query to the LDAP server; 

receiving the digital certificate data from the LDAP server during one or more 
passes during execution of the query; 

determining if the digital certificate data received exceeds a threshold; 
upon a determination that the digital certificate data received exceeds a threshold: 
15 throttling the digital certificate data received to create throtded digital 

certificate data; and 

transmitting the throtded digital certificate data to the mobile device in a 
single pass; and 

upon a determination that the digital certificate data received does not exceed a 
•20 threshold, transmitting the digital certificate data received to the mobile device in a single 
pass. 

38. The method of claim 37, further comprising the step of compressing the 
digital certificate data and the throtded digital certificate data prior to transmitting the 
digital certificate data and the throtded digital certificate data to the mobile device. 
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39. The method of claim 38, wherein the step of throttling the digital certificate 
data received to create throttled digital certificate data comprises the step of selecting only 
the threshold amount of the digital certificate data received for transmission to the mobile 
device in a single pass. 

5 40. A system for handling a Lightweight Directory Access Protocol (LDAP) 

service request to an LDAP server for an LDAP service, the system comprising: 

handler means for receiving the LDAP service request data corresponding to the 
LDAP service request and executing the LDAP service request to the LDAP server, for 
receiving LDAP service reply data from the LDAP server during one or more passes, for 

10 throttling the LDAP service reply data to generate throttled LDAP service reply data, and 
for transmitting the LDAP service reply data or the throttled LDAP service reply data; and 

cUent means for generating the LDAP service request data corresponding to the 
LDAP service and transmitting the LDAP service request data to the handler means, and 
for receiving the LDAP service reply data or the throttled LDAP service reply data from 

15 the handler means. 

41 . The system of claim 40, wherein the handler means is furtlier adapted for 
appending refinement data to the throttied LDAP service reply data and for transmitting 
the refinement data with the throttied LDAP service reply data. 

42. The system of claim 41, wherein the handler means is further adapted for 
20 compressing the LDAP service reply data and tiie throttied LDAP service reply data prior 

to transmission. 

43. A system for accessing digital certificates stored in a Lightweight Directory 
Access Protocol (LDAP) server, the system comprising: 

a client program executable on a client system, the client program operable 
25 to generate an LDAP query requesting digital certificate data and provide the LDAP query 
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for transmission from the client system, and further operable to receive digital certificate 
data in response to the LDAP query; and 

a handler program executable on a handler system, the handler program 
operable to receive the LDAP query transmitted from the client system and execute the 
5 LDAP query, receive the digital certificate data in response to the LDAP query during one 
or more passes, and upon completion of the execution of the LDAP query, provide the 
digital certificate data for transmission to the client system in a single pass. 

44. The system of claim 43, wherein the handler program is further operable to 
throttle the digital certificate data to generate throttled digital certificate data if the digital 

10 certificate data exceeds a threshold, and provide the throttled digital certificate data for 
transmission to the client system in a single pass. 

45. The system of claim 44, wherein the handler program is further operable to 
append refinement data to the throttled digital certificate data and provide the refinement 
data for transmission to the client system. 

1 5 46. The system of claim 45, wherein the client program is further operable to 

generate a revised LDAP query for digital certificate data in response to receiving the 
refinement data and provide the revised LDAP query for transmission from the client 
system. 

47. The system of claim 46, wherein the client system comprises a mobile 
20 device operable to communicate over a wireless network. 

48. The system of claim 47, wherein the handler system comprises a wireless 
gateway. 

49. The system of claim 47, wherein the handler system comprises an LDAP 

server. 

36 



wo 03/079639 PCT/CA03/00407 

50. The system of claim 47, wherein the handler system comprises a redirector 

system. 

51 . A system for accessing digital certificates stored in a Lightweight Directory 
Access Protocol (LDAP) server, the system comprising: 

a handler program executable on a handler system, the handler program 
operable to receive an LDAP query requesting digital certificate data from a client system 
and execute the LDAP query, receive the digital certificate data in response to the LDAP 
query during one or more passes, and upon completion of the execution of the LDAP 
query, throttle the digital certificate data to generate throttled digital certificate data, and 
provide the digital certificate data or throttled digital certificate data for transmission to the 
client system in a single pass. 

52. The system of claim 50, wherein the handler program is further operable to 
append refinement data to the throttled digital certificate data. 

53. The system of claim 52, wherein the handler system is a wireless gateway. 

54. The system of claim 53, wherein the client system is a mobile device. 

55. The system of claim 52, wherein the handler system is an LDAP server. 

56. The system of claim 55, whereha the client system is a wireless gateway. 

57. A method for accessing encryption data stored in a database server, the 
encryption data requested by a client system, the method comprising the steps of: 

receiving at a handler system a database query for the encryption data, the query 
transmitted from a mobile device; 

executing at the handler system the database query to the database server; 

receiving the encryption data from the database server during one or more passes 
during execution of the query; and 

transmitting the encryption data received to the mobile device in a single pass. 
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58. The method of claim 57, further comprising the steps of: 
determining if the encryption data received exceeds a threshold; and 
if the encryption data received exceeds a threshold: 

throttling the encryption data received to create throttled encryption data; 

and 

transmitting the throttled encryption data to the mobile device in a single 

pass. 

59. The method of claim 58, wherein the step of throtding the encryption data 
received to create throttled encryption data comprises the step of selecting only the 
threshold amount of the encryption data received for transmission to the mobile device in 
a single pass, 

60. The method of claim 59, wherein the encryption data comprises digital 
certificate data. 
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